\newcommand{\refer}[1]{\autoref{#1}, \emph{\nameref{#1}}}

\chapter{Introduction}
\label{cha:intro}
	\section{Project description}
	\label{sec:prj-descr}

		This document exposes the research conducted for the development of an USB 802.15.4 %(explained at \autoref{ssec:802.15.4}) 
		receiver device for Android based systems employed in a fully 
		functional electrocardiogram monitoring system encompassed in the field of in-home healthcare,
		as well as the development process involved in the realization of this whole system.\\
		% in-home healthcare personal healthcare?

		% What is Personal-healthcare, what is ECG Monitoring, importance of a lowcost ecg monitoring system
		Electrocardiogram (ECG) monitoring consists of the capture and interpretation of the activity of the heart during a period of time, and continuous, remote ECG monitoring has become one of the main applications of wireless body sensor networks. Great interest has arisen recently among industrial and academic research parties in production of low-power, ambulatory ECG monitoring systems.\\

		In order to maximize portability, such systems have started to employ the widely available smartphone devices as frontends, reducing the amount of extra devices carried by the user to just the ECG capturing node. In 2011 the Complutense University of Madrid (UCM) in collaboration with the École Polytechnique Fédérale de Lausanne (EPFL) presented a real-time personal ECG monitoring system which displayed data in an iPhone via Bluetooth \cite{ESL}.\\

		% Taking the aforementioned project as the base, this project seeks taking the inherently good low cost and low power aspects of that to the next level by the employment of a less energy requiring wireless personal area network protocol, namely IEEE 802.15.4, and the more accessible Android based platforms.\\
		Being inspired by the results obtained by the aforementioned project, this certain  endeavour seeks taking the inherently good low cost and low power aspects of that to the next level by the employment of a less energy requiring wireless personal area network protocol, namely IEEE 802.15.4, and the more accessible Android based platforms.\\

		% Tareas asumidas por el sistema para expresar el ambito del proyecto
		The system which is to be developed in this project provides the user with a visual representation of his/her ECG wave in real-time highlighting relevant points of this in order to simplify its comprehension. Information about heart-beat-rate % and arrhitmia?
		is also displayed. All this data is stored in a transparent to the user manner for later visualization with emphasis put in easy handling of the generated files.\\

		\begin{comment}
		¿Qué es cada parte?
		Sistema 3 partes: nodo delineador, receptor 802.15.4 y app como frontend en general. En un parrafo distino para cada una explicar las tecnologías que hemos usado y porque. 

		¿Cómo se hizo cada parte?
		(Orden, android ->shimmer->msp430->dirigir texto hacia investigación(flecha = parrafo))
		Visualizador: Android ampliamente usado, facilidad para obtener un dispositivo, no demasiado coste (al menos < iOS), plataforma abierta, desarrollo comodo.
		Shimmer: reutiliza sistema desarrollado por la complu en colaboración con EPFL
		Receptor: 

		\end{comment}
		% Three parts of the system, description of each one (what do they do?)
		This functionality is provided by the three devices that are part of the system: the ECG delineation node, the USB 802.15.4 receiver and the Android device through the front-end application. The ECG delineation node is connected to the body sensor network and is responsible for capturing and analyzing the electrocardiogram wave, as well as encoding and wirelessly sending the data. The USB 802.15.4 receiver is plugged to the Android system and manages data reception following the aforementioned protocol. Finally the Android based application is the real-time data decoder and acts as the frontend to the user, managing connections and storing and displaying received data.\\

		% Description of the realization of each one (how do they do whatever they do?)
		Development of the Android application, realization of the real-time USB 802.15.4 receiver device, employment of an already-existant ECG delineation node and successful intercommunication between all these elements are the project goals.\\
		
		% Android app
		As stated before, the Android application is the front-end with which the user interacts with the whole system. It is designed following Android common practices as the objective is for it to be of simple use with a smooth, if not nil, learning curve. The decision to develop the application for Android platforms was made according to three main reasons:\\

		First, the fact that Android has been in the top three of the most used mobile operating systems rankings since 2010 \cite{androidSpread} added to the recent growth of the availability of smartphone devices \cite{sphoneStudy} makes targeting the Android platform a must when the objective is making the system reachable for as most people as possible.\\

		Second, and following the same line of reasoning, the lower cost, in general terms, of Android supporting devices, or at least the wide range of prices of these, specially when compared to other operating systems supporting devices such as Apple's range of iOS devices is to be taken into account.\\

		And finally the comfortable, high-level development environment available for Android application production \cite{andDev-what} provides enough facilities for anyone interested in expanding or contributing code to the Android part of the project to do so in an easy way. Moreover, this environment is delivered free of charge and is of an open-source nature and multiplatform \cite{andDev-sdk}, whereas iOS platform development kits usage requires at least the ownership of an specific machine and operating system \cite{iosDev}.\\

		% Delineation node
		Regarding the ECG delineation node, it has been mentioned that the objective of this project is the employment of an already existing one. That is so because both the delineator node and the body sensor network that captures the data are complex systems and the development of them would be the scope of a full project. Specifically the delineator node obtained in the aforementioned project \cite{ESL}, with modifications from another collaboration between the UCM and the EPFL \cite{ecg.del.paper}, was applied.\\

		This node was originally developed as a ultra-lowpower real-time ECG delineator with the ability to wirelessly send data through Bluetooth protocol. The collaboration between UCM and EPFL, among other things, provided the node with functionality to send data using IEEE 802.15.4, but only at the level required to do some measurement and estimations \cite{ecg.del.paper}. Actual 802.15.4 utilization was yet to be a reality, but it was an excellent starting point towards the achievement of the current project objectives.\\

		% USB Receiver
		The key part of the system and the most important risk involving objective of the project is the real-time 802.15.4 USB receiver device for Android platforms. It is a necessity as Android devices generally have no support for low cost wireless communication protocols such as 802.15.4, while providing other higher-cost protocols such as Bluetooth or Wi-Fi. Development of an Android accesory providing the required functionality is, then, a must, as the most battery and time consuming operation in the delineator node is the utilization of the Bluetooth stack, as previously mentioned researches \cite{ESL} and \cite{ecg.del.paper} concluded.\\

		Other projects exist with the objective of achieving 802.15.4 reception for Android devices, even if they are not targeted at the field of biomedics and personal monitoring. The reason for not following or employing those is twofold: 
		first, at the time of the beginning of the project those initiatives were either unfinished or stalled (as it can be seen in \cite{and-zigbee}), furthermore they were isolated, generally single-man projects with no official backend or guarantees of conclusion.
		Second, following the line of achieving a low energy, low sized device the Android system of this project is to act as the host device in the USB communication, thus removing the size-increasing battery requirements for the receiver as the host role provides the power in such communications. None of these projects employed the host capability of Android devices, so they were of no use for the pursued objectives.\\

		In short, this project tries to advance a step further the availability of wireless body sensor networks applied to personal electrocardiogram monitorization, by employing actual, already available, not-so-expensive technologies in an effective manner. That is necessarily good by nature, and the main motivation for braving with the project, aside from those, more pragmatic, exposed in the next section, is the wish for it to be useful, some day, for someone.

		\begin{comment}
		In short, the main objective for this project, seen as a whole system, consists of
		visually and wirelessly displaying and managing data obtained from portable, personal ECG-monitoring
		emitter devices on an Android tablet, paying special attention to make possible the communication
		with Android through 802.15.4. In order that the system can operate that way, the following 
		issues will have to be resolved:
		\begin{enumerate}
			\item \emph{Communication with 802.15.4 emitters}\\
				Android devices are usually equipped with Bluetooth radio modules, so it is likely that they 
				count with working Bluetooth communications out of the box, which is the case of the target
				device, a Motorola Xoom tablet.
				However, 802.15.4-compliant communication is not natively supported by any existing Android
				device --not even any other widely known portable computing device--, so it will be needed % which leads to the following goal for the project to fulfill. \\
				the development of an alternative method for achieving this goal. As the next item states,
				the solution to this problem consists of building up a receiver accessory capable of connecting
				to the tablet through USB interface. This particular task centers most of the efforts dedicated
				to the project, since it is both crucial for the proper operation of the system and unprecedent
				in its field, as it will be detailed later.
			\item \emph{Android accessory development}\\
				As it was stated before, Android-powered devices are usually equipped with Bluetooth radio
				modules, yet they lack the capability to communicate with devices which implements other 
				standards. In order to achieve this feature for this sort of device, development of an
				specifically designed accessory is both a required and mandatory task.\\
				The aforementioned support Android OS provides for USB device and host modes would allow us to
				obtain data processed by the accessory through an available interface for almost every 
				Android device. In particular, USB host mode would be required so that the Android device 
				were to be able to power the accessory, hence the restriction of using devices running
				Android version 3.1 or newer.\\
				For this goal an USB-capable board equipped with an MSP430 microcontroller was chosen for acting
				as the receiver accessory. More specifically, this microcontroller would be running FreeRTOS
				(operating system oriented to tasks with real-time needs), which would be accordingly modified
				for dealing with the USB interface and 802.15.4 communication.\\
				It is also noteworthy that the usage of a prototyping board and a potential miniaturisation of
				the previously described board were included into the scope of this objective as well. Besides, 
				full description and more details about this development and 802.15.4 communication can be found 
				at \autoref{ch:hardware}, \nameref{ch:hardware}.\\
			\item \emph{Android ECG application}\\
				Finally, an Android application acts as the system's frontend. Its most relevant requirements were
				determined by the existing EPFL iOS application, with subtle modifications due to the different
				platform as well as the inclusion of an extra accessory.\\
				The data the application displays, in the shape of ECG waves, may be retrieved from a Bluetooth
				or 802.15.4 streaming node or a local log file. These logs are written by the application itself
				as it receives an incoming data transmission, so that it can replay them later --original
				iOS application lacked this feature--.\\
				Moreover, view controls shall also be offered for the user to modify display density, and move
				forwards and backwards if a log is being displayed.\\
				More information about the application, such as requirements and other details, can be found
				at \autoref{ch:swdev}, \nameref{ch:swdev}.\\
		\end{enumerate}
		\end{comment}
		
	\section{Project driver}
	\label{sec:prj-driver}

		The motivation for the realization of this project comes from two different areas: the further potential utility of the project and the academic interest it involves.\\

		The potential utility of the project point of view is developed first.\\

		\begin{comment}
		x CardioVascular Diseases (CVD) as high risk, expanded cause of death (citamos a la OMS)
		x WBSN as a cheap, efficient method of monitoring, particularly ECG monitoring for CVD preventing.
		x Smartphones as ubiquous monitoring window.
		x EPFL's shimmer + iPhone bluetooth monitoring system.
		x Bluetooth battery requirements don't suffice for expected device usage time.
		x 802.15.4 as a more efficient alternative.
		x Smartphones not equipped with 802.15.4 -> Development of a receiver device.
		x Android as more open, flexible, expanded platform than iOS.
		x .·. Android + 802.15.4 (through a receiver device) + shimmer for continous ECG monitoring.
		\end{comment}

		Cardiovascular diseases are the number one cause of death globally, according to the World Health Organization \cite{who-cvd}. The level of supervision required by affected people is usually not assumible by traditional health care institutions, and constant, in home monitorization is an objective yet to fulfill which can be of great help for affected inviduals.\\

		In such an scenario wireless body sensor networks (WBSN) prove to be inexpensive, efficient monitoring tools. Specifically electrocardiogram monitoring applied WBSN are of great utility for constant tracking of cardiovascular diseases, and projects as the aforementioned UCM and EPFL collaboration pursue the realization of a wide employment of these systems.\\

		The employment of smartphone devices as the monitoring display of the system targets the wide spreading of the application of these systems, and reduces the amount of devices to be carried by the user. The selection of Android as the base platform for the display part this project, as explained before, is made attending to two factors: the higher expansion of the Android operating system when compared to others, and the flexible, open-source nature of it. These are key for the further expansion and application of the system.\\

		Reducing battery and size requirements also targets a higher employment of the system by simplifying the usage procedure: lower battery requirements involve less monitoring interruptions due to the charging of the system and lower sized devices allow higher portabilty and more constant monitorization. The employment of the 802.15.4 wireless protocol seeks the fulfillment of this objectives.\\

		In conclusion, the employment of an 802.15.4 receiving enabled Android device in a real-time, continous ECG monitoring system reduces the battery and size requirements for the system, maximizing portability and lessening the restrictions on the applicability of it.\\

		From an academic point of view, the main motivation for the development of this project is the fact that it means
		the gathering of almost every branch of the Computer Science and Engineering career. From its very beginning, the
		project involves both software and hardware development, researching on out of the scope of the career 
		tools and platforms as well as high and low-level design and programming.\\

		% Besides, if successful, it would be likely it could become a real product
		% and be useful both in a professional and particular scope, which added a practical
		% end for the work to be carried out. Something like this could be made thanks to
		% the special features --such as less power consumption and required investment-- 802.15.4-compliant
		% technologies provide which wider spread ones lack (Bluetooth, for instance). 
		It is also
		expected that technologies based on IEEE 802.15.4 specification like ZigBee will increase their
		importance in the medium term due to their potential applications in domotics (home automation) and other areas.\\

		In addition, both the development of applications and accessories for smartphones or other portable devices
		are mainstream, highly demanded activities nowadays and getting in touch with these
		provides extra experience at leading edge practices, which broadens our areas of
		expertise and, consequently, increment our value in the labour market.\\

		% However, certain areas of the project would mean working on unprecedent techniques
		% --as it will be detailed later on within this section-- and dealing with tools
		% which were unknown for us at that moment. Hitches like these could lead to the
		% unfulfillment of the project, yet they could also add extra value to it if 
		% they were overcome.\\
		
	\section{State of the art}
	\label{sec:prj-sota}
		\begin{itemize}

			% Añadir otro item de monitorizacion, onads P QRS y T etc etc. no solo EPFL si no en general, y luego ya EPFL concret
			\item \emph{UCM and EPFL ECG monitoring Project}\\
				As a precedent of the present project, the Complutense University of Madrid (UCM), along with 
				the École Polytechnique Fédérale de Lausanne (EPFL) --represented by its Embedded Systems Laboratory
				(ESL)--, developed a wireless ECG monitoring system \cite{ESL}, similar to the one has been built 
				up during this project.\\

				Just as ours, this system also used Shimmer\texttrademark as monitoring, transmitter platform 
				(details about it can be found at \autoref{ssec:shimmer}); and the obtained data could be 
				displayed in portable computing devices.
				Nonetheless, the list of similarities ends there. The application responsible for rendering
				the ECG waves was meant to be used over iOS devices, particularly iPhone. This fact led to several
				additional restrictions, such as mandatory usage of Bluetooth as wireless transmission method as
				well as the need of ``jailbreaking'' the device itself. This process allows the user to gain root access to
				the OS, and it was needed in order that a explicitly installed Bluetooth stack allowed the device to 
				receive the emitted data properly. However, according to the manufacturer \cite{AppleJB}, jailbreaking 
				the device nulls its warranty. Therefore, the employment of Android in our project is partially motivated 
				by this sort of limitations other platforms usually impose.\\

				Whereas the UCM was responsible of the delineation algorithm, the development of the iOS application
				was carried out by the EPFL, and thus the development of this project depended on the feedback and requirements
				(hardware and software) both of them provided. In fact, the aforementioned iOS application settled most of the
				requirements for the Android one in this project, although there were added some extra ones --such as
				making logs from received data so they can be read again later--.\\
				
			\item \emph{IEEE 802.15.4}\\
				This standard describes the physical and Media Access Control (MAC) layers for low-rate wireless
				personal area networks. It is intended to be implemented into embedded devices, so as to build up
				short-range networks --10 meters, typically-- with narrow bandwith, up to 250kbps, among other
				possibilites with lower transfer rates. It is a relatively new standard since its first version
				was approved in 2003, although the following revision was employed during this development, which
				was approved in 2006 \cite{802.15.4}.\\

				802.15.4 is specially suitable for this kind of project due to its low power consumption. In
				fact, ZigBee, which uses this standard as its low-level layer, presents a series of advantages
				over Bluetooth, underlying technology of the previously mentioned EPFL and UCM project:
				\begin{itemize}
					\item \textbf{Lower power consumption:} without going into detail, it can be stated that Bluetooth 
						requires more power than ZigBee does. For example, Bluetooth is constantly emitting information,
						consequently consuming power, while 802.15.4 allows to enable the radio only when it is needed.
						These statements are properly justified and explained at \autoref{ssec:802.15.4}, 
						\emph{\nameref{ssec:802.15.4}}.
					\item \textbf{Bandwidth:} Bluetooth offers much wider bandwidth, up to 3Mbps, meanwhile ZigBee 
						only offers up to 250kbps. This, however, is not a relevant disadvantage because the requirements
						of the system are not so demanding.
					\item \textbf{Host number:} ZigBee allows to build networks with up to 65535 hosts, subnetworks 
						with 255 hosts. On the other hand, Bluetooth can only support as much as 8 hosts within a 
						network. 
				\end{itemize}
				ZigBee, though, is not employed as a whole within this project, but 802.15.4 standard as
				its basis (its MAC layer, more precisely). Nevertheless, its advantages over Bluetooth remains the same, with the additional one
				that it does not compromise real-time developments as the complete stack does.\\
			\item \emph{Android Accessory Development}\\
				As of May, 2011, there were no easy nor official methods to develop accessories capable of 
				communicating with Android running devices. At that certain time, the release of the Android 
				Open Accessory Development Kit (also known as ``ADK'') \cite{ADK} was announced in San Francisco, 
				within the context of Google I/O, developers conference arranged by Google \cite{GoogleIO}.\\

				ADK consists of an USB microcontroller board based on Arduino (Arduino Mega2560 to be precise) and a
				series of software libraries which add specific functionalities and support for other hardware add-ons,
				typically known as \emph{shields}, that equip the accessory with sensors or interactive elements
				which broaden its capabilities. Shields are plugged to the board through its numerous input/output
				pins, which also allow the connection of personally crafted hardware additions --allowing that way to
				create tailored behaviours, following the Arduino's ``Do It Yourself'' (DIY) spirit.\\

				With the release of that kit, Android project opened itself to the development
				of all kind of new accessories which would add potential and functionalities
				it lacked.\\

				As well as this kit, the following release of Android 3.1 API version completed
				the accessory ecosystem with the inclusion of directly supported host and device
				USB modes --this support was also backported to Android v2.3.4; only the device mode, though--.
				By doing so, Google completely cleared the way for the development of Android-compatible accessories, 
				which was previously reduced to the underlying, quite complete but not enough, Linux kernel driver 
				support.\\
			\item \emph{ZigBee dongles}\\
				In spite of the fact that there were available devices which implemented the complete ZigBee
				stack at the time of the start of this project, they were only designed for being connected to
				personal computers, some models with OS restrictions as well. A typical model of this sort is
				presented in \cite{dongle}.\\
				Moreover, even if they were to be compatible with our target device, the only available dongles
				fully implemented the ZigBee stack, which also made them unsuitable for this project due to the
				relatively high latency that fact imposed --as it can be read at \autoref{ssec:802.15.4},
				\emph{\nameref{ssec:802.15.4}}, real-time needs required the usage of the 802.15.4 MAC layer on
				its own--.
			\item \emph{Communication with Android using ZigBee}\\
				One year ago, around mid-2011, there were very few projects which were working on this sort of
				communication, between Android and 802.15.4 radio-equipped devices. Concretely, the only noticeable
				project of this kind was one from Texas Instruments, which was stated to be pioneer in 
				this field (as it can be seen in \cite{articleTI}). Despite that, several differences stands between 
				this project and the present one. For instance:
				\begin{itemize}
					\item \textbf{USB communication:} Texas Instruments developed its own Android driver, namely
						``virtual COM port'', so they could directly connect their ZigBee Network Processor (ZNP)
						to the Android device through USB. Instead, Android USB host mode is used in this project
						in order to establish the connection between the receiver and the device. Because of
						using this method, USB communication between MSP430 microcontroller and the Android
						device has to be specifically implemented and tuned.
					\item \textbf{Android platform:} TI's project employed Android 2.2, while version 3.1 is the
						one employed in this present project, due to the aforementioned need of USB host mode support 
						this API provides. In addition, received data is used by this Android application, while TI
						employed ZigBee communication for less specific ends, such as controlling other devices
						like PCs, lamps or obtaining data from certain sensors.
					\item \textbf{Wireless communication:} in order that the ECG delineation could be done in
						real-time, this project does not use the complete ZigBee stack, but its 802.15.4 MAC
						layer. This restriction requires the radio --in particular, TI CC2420 radio module-- has
						to be programmed specifically. Meanwhile, Texas Instruments made use of its TI CC2530 system on chip (SoC), which fully implemented ZigBee stack.
					\item \textbf{USB dongle:} as it was mentioned before, TI directly plugged their ZNP to an
						OMAP4 Blaze thanks to their driver. However, so that the same result could be obtained,
						the radio, CC2420 module, had to be connected to the MSP430 board, namely the MSP-TS430PZ100USB,
						which was equipped with a USB interface. Furthermore, miniaturisation of this board was
						designed afterwards to make it an usable dongle.
				\end{itemize}
				In other words, Texas Instruments' project was actually able to build up working communications
				of this kind by the time ours was starting; all the same, special requirements like real-time
				needs entail additional challenges for this project to overcome.
		\end{itemize}
	
	\section{Document overview}
	\label{sec:prj-oview}
		% Over the following pages, this document will present the details about the project it refers to.
		% Beginning with a thorough explanation about the	employed hardware and the work it required,
		% which can be found at the ``\nameref{ch:hardware}'' chapter; next, a deep description and analysis 
		% of the Android application's design and implementation; and, finally, an exposition of the obtained 
		% results, potential expansions and findings.  
		This document presents the process involved in the realization of the project objectives. Discrimination of the hardware and the software parts of this process is mandatory, as the approach for each one, the applied methodologies and techniques as well as the development processes, differ.\\

		The first chapter, this introduction, gives a global view of the project. A description of the project providing a detailed depiction of the objectives pursued, as well as the inspiration for it's development and an exposition of technologies applied is elaborated in \autoref{sec:prj-descr} \emph{\nameref{sec:prj-descr}}. The motivation leading to the undertaking of such project is presented then, explaining the reasons both from the project potential utilization and the academic interest of the project points of view. This explanation is conducted in \autoref{sec:prj-driver} \emph{\nameref{sec:prj-driver}}. The next section, \autoref{sec:prj-sota} presents the state of the art regarding the technological fields and technologies involved in the project. The chapter concludes with this overview of the document in \autoref{sec:prj-oview} \emph{\nameref{sec:prj-oview}}.\\
		
		The research and development of the hardware part of the project in order to obtain the 802.15.4 USB receiver is presented in \autoref{ch:hardware}, \emph{\nameref{ch:hardware}}. It begins exposing the specific objectives pursued by this part of the project and providing an overview of the chapter in \refer{sec:hw-intro} and \refer{sec:hw-oview}. A detailed description of the technologies employed in the hardware development process is then provided in \refer{sec:hw-techs}. The specific process, methods and techniques applied in the hardware development are presented in \refer{sec:hw-descr}. The remaining part of the chapter is devoted to the description of the actual research and development conducted throughout the whole project time. First, an explanation of the project schedule, as well as the specific circumstances which led to it being as it is, is provided in \refer{sec:hw-mstones}, followed by detailed exposition of the development of each stage of this schedule. The chapter concludes with the analyisis of the final hardware product and an exposition of the conclusions obtained during the process in \refer{sec:hw-final}.\\

		The third chapter, \emph{\nameref{ch:swdev}}, explains the process followed for the production of the Android application which acts as the ECG monitoring front-end employing artifacts from structured software development methodologies so as to provide an in-depth view of the software part of the project. In \refer{sec:sw-intro} and \refer{sec:sw-oview} a brief description of the software project and an explanation of the information contained in the scope of the chapter are presented. The identified requirements for the project, both functional and non-functional, are presented in \refer{sec:sw-reqs}. In the next section, \emph{\nameref{sec:sw-risks}}, the importance of the risk management for this particular project is demonstrated and the identified risks exposed, including their evolution throughout the project development. The analysis process view concludes with the exposition of the use cases for the system in \refer{sec:sw-ucases}. The \emph{\nameref{sec:sw-arch}} section presents the architectural view of the system, explaining design considerations and system modules in a comprehensive manner. The project development process is exposed in \autoref{sec:sw-process}, beginning with an explanation of the software project schedule which is followed by detailed descriptions of each of the project scheduled iterations, including risk evolution and use case realization related information. The chapter concludes with a review of the software project development in \refer{sec:sw-ending}.\\

		In the final chapter of this document a review of the project as a whole is conducted. First, the final state of the system is presented in \refer{sec:end-state}, detailing the accomplishment of each project objective so as to evaluate the project outcome. Taking the final state of the project as the starting point, potential further work lines are proposed in \refer{sec:end-further}. Finally, as a closure to both the document and the project, \refer{sec:end-findings} explains the conclusions drawn from the development of the project.\\

		Three appendices are attached to this document. The first of these, \refer{ch:budget} presents an estimation of the cost of the project including performed tasks and scheduling in \autoref{sec:sched}, as well as a Gantt chart for this scheduling in \refer{sec:gantt}. The total cost of the development is exposed in \refer{sec:cost}.\\

		\refer{ch:cost} refers the cost of the production of both a single unit and a batch of ten thousand units of the receiver device, the latter as an estimation of the costs in a mass production scenario.\\

		The documents produced in the process of design and development of the receiver device are presented in \refer{ch:specs} with enough detail to allow custom production of the device. The bill of materials, the device schematic and the printed circuit board design are also included.\\
